Torno ad occuparmi un po' dei cluster...
Riguardo alle tecnologie di parallelizzazione di un programma, si ricorda che questo deve essere adatto allo scopo, e cioè deve presentare la possibilità di dividere l'onere computazionale in più threads (il processo è l'immagine in RAM del programma, mentre il thread è l'unitò granulare in cui un processo è suddiviso) i quali, per farla breve, possono essere distribuiti su più unità logiche.
Per chi inoltre si domandasse il perchè di riscrivere un programma per l'esecuzione in cluster, basti sapere che un processo, per essere eseguito dopo essere stato compilato con un compilatore "comune", ha bisogno di "andare a parare" su una singola unità logica che lo gestisca. La parallelizzazione è attuata attraverso l'implementazione ad esempio di un protocollo di comunicazione fra diverse macchine, come le librerie MPI. Le virtual machine che girano in cluster non esistono appunto per questo motivo e per il fatto che "emulare" un processore farebbe colare a picco le prestazioni (provate a installare Virtual PC sopra una macchina virtuale in Vmware e poi raccontatemi...).
Tornando a noi, mi occuperò in questo articolo di definire degli scenari per l'esecuzione di codice parallelo attraverso l'uso (e quindi la preventiva costruzione) di cluster adatti allo scopo.
Fra le infinite possibilià offerte dal mercato dei software e dal mondo OSS, mi sento di portare all'attenzione due di queste, caratterizzate prevalentemente da facilità e velocità di implementazione. Parto inoltre dal presupposto che il parco macchine usato per il cluster sia un ambiente Windows, con pc relativamente recenti e collegati con Ethernet 10/100, scenario molto tipico in aziende e istituti di educazione e/o ricerca).
Il primo scenario proposto prevede la costruzione di una macchina SMP (Symmetric Multi-Processing, che è il modo per mettere più CPU in parallelo usato dai recenti processori multi-core) con OpenMOSIX, progetto purtroppo non più seguito dagli sviluppatori dal 1° dicembre 2007. L'idea è quella di eseguire in Vmware Server 1.0 (che è gratuito) il sistema operativo ClusterKNOPPIX o ParallelKNOPPIX, che costituirà il nodo principale del cluster. Per usare tutte le altre macchine Windows, si può installare e configurare
coMosix, che è bene configurare prima di fare il boot della virtual machine con Linux. Per la configurazione seguire il tutorial nel sito del pacchetto (niente di particolarmente difficile).
Abbiamo così a disposizione una macchina SMP in Linux, il tutto senza intaccare le installazioni Windows. Questo scenario è efficace fino a 16 macchine, dopodichè le prestazioni calano in picchiata. Inoltre è possibile usare la configurazione di rete già esistente. Consiglio di avviare manualmente (in locale o in remoto) il servizio di coMosix, per evitare che il processore fisico di ogni machcian venga occupato inutilmente se Linux (nodo principale del cluster) non è in funzione (questo per evitare usi indesiderati della CPU host, perchè la rete usata dal cluster è la stessa di quella fisica e inoltre il "padre" di coMosix, coLinux, occupa permanentemente una CPU su due in Pentium 4).
Da ricordare infine che il cluster così costruito è una macchina SSI (cfr. tassonomia di Flynn), e può essere usato con programmi che sono compilati per CPU multicore.
Il secondo scenario proposto riguarda la recente possibilità di usare il nuovo Windows Server Cluster Edition (o il nuovo Windows 2008 HPC), che gira solo su piattaforme a 64 bit. L'idea qui è di distribuire in ogni macchina Virtual Server 2005 R2 Sp1 (la versione Standard fa al caso nostro) e una installazione virtuale del sistema operativo suddetto. Va da sè che le macchine host devono avere il sistema operativo a 64 bit per poterlo ospitare, e le prestazioni migliori sono raggiunte se hanno anche 4GB di RAM, di modo che possiamo attivare da BIOS la virtualizzazione assistita tramite hardware. In questo modo ancora una volta non si intacca l'installazione e la configurazione delle macchine host, anche se la procedura è più onerosa in termini di tempo. Per chi avesse tutte le installazioni di Windows a 32 bit, allora la scappatoria sta nel fatto di usare Vmware per l'emulazione, che permette di installare anche OS a 64 bit se il processore fisico supporta queste istruzioni). I vantaggi della piattaforma Microsoft sono la maggior scalabilità e le migliori prestazione del cluster, che differisce da OpenMOSIX per efficienza e sistema di distribuzione del carico (è molto simile ad un grid). Conviene preparate un'immagine quorum del disco in formato VHD da distribuire fra le macchine, magari con SysPrep per eseguire il mini-setup iniziale. L'emulazione va fatta con due schede di rete virtuali, una che comunica con l'esterno al solo scopo di raggiungere il controller di dominio esistente in azienda, e l'altra, con sottorete diversa, per le comunicazione del cluster. Per coloro i quali la sicurezza del cluster non è un problema, basta la rete locale normale (se il cluster però è di tipo load balancing o fail-over, separare le interfacce è consigliato). Una volta terminata la distribuzione, seguire i wizard di installazione del cluster, particolamente semplici e intuitivi. Credo appaia ovvio che questo tipo di installazione pesa molto di più nelle macchine host di quella precedente, ma ha il vantaggio, per alcuni forse fondamentale, di poter eseguire codice parallelo in macchine Windows.
Infine segnalo per completezza la Sun N1 Grid Engine, che ha prestazioni vicine al secondo scenario, e altri modi per usare Windows in cluster come quello offerto dalla software house Digipede.
Per chi come me fosse interessato a far girare Matlab in un cluster, allora è possibile usarlo, nella edizione per Linux, con il primo scenario, poichè dalla versione 2007a Matlab supporta gli SMP (particolarmente adatta al calcolo in parallelo è l'inversione di matrici); dato comunque che il riconoscimento dei processori disponibili nel cluster non è così automatico, alcuni suggeriscono di usare tool come JavaParty o JavaPorts per eseguire vecchie versioni di Matlab in parallelo. Indico anche altre possibilità in Matlab a livello di codice, come la Distributed Computing Engine (integrata), oppure le librerie MPICH per Matlab.
